Security concerns for all types of processor-based electronic devices, and particularly for computing devices, have become significant. While some concerns may relate to detrimental actions which may be undertaken by defective code implemented by such devices, the greater concerns relate to the ramifications of various types of attacks made upon such devices through malicious code, including code conventionally known in the field by a number of names, such as “viruses,” “worms,” “Trojan horses,” “spyware,” “malware,” and others. Many of these attacks are directed at computing devices, such as workstations, servers, desktop computers, notebook and handheld computers, and other similar devices. Many of these computing devices can run one or more application programs, which a user may operate to perform any number of desired functions.
A number of methodologies have been used in an attempt to reduce or eliminate both the attacks and influence of malicious or defective code. Generally, these methodologies include detection, prevention, and mitigation. Specifically, these methodologies range from attempts to scan, identify, isolate, and possibly delete malicious code before it is introduced to the system or before it does harm (such as is the objective of anti-virus software, and the like), to restricting or containing the actions which may be taken by processes affected by malicious or defective code.
Most modern computer systems employ operating systems that support graphical user interfaces, or, “GUIs”. Central to these operating systems is the use of a low-level application referred to as a “window server.” One function of a window server is to receive, annotate and route signals from external devices (e.g., human interface devices such as keyboards, pointer devices and tablets) to the appropriate application (e.g., an audio, video or multimedia application). Typically, the window server manages all windows accessed by programs running within a data processing system, including granting accesses to the programs. As more and more programs are running in the system and more and more GUIs are utilized by the programs, the process for granting and managing the access of GUIs becomes more complicated and inefficient.
Prior art attempts to manage authority designation in GUI-based computer systems, such as those described in U.S. Pat. No. 8,365,192, published Jan. 29, 2013and entitled “Methods for Managing Authority Designation of Graphical User Interfaces,” which is hereby incorporated by reference as if reproduced in its entirety, have attempted to set up “handshaking” schemes between a graphics management system, such as a window server, and the various processes that are attempting to offer and accept access to and from one another. However, these schemes have certain limitations. In particular, because windows were used as the “fundamental basis” of implementing authority designation in such window server-based management schemes, actions that should have treated all content and/or state spanning multiple windows in a self-consistent interface couldn't do so because, if there was an out-of-process window being presented as part of what the user thought was his or her application, there would potentially be lag in communication when certain user changes had to be rectified.
For example, in the case of a user request to resize a window, normally, an application would respond to the resize request in a very controlled manner, so that the user is not shown a half-drawn window (i.e., so as to avoid the phenomenon known as “window tearing”). This could be achieved by, e.g., recognizing the window resize up to a certain point, redrawing everything in the window, flushing that content to the screen, and then, if the window has been resized further since the screen flush, realizing the new resize request so that, when the window content reflows to the screen, it feels fluid and tearing is avoided. However, if the window being resized is “pretending” that some particular content is part of itself (e.g., by relying on position and sizing of content in a higher (z-order) window), but some other process is actually rendering that particular content, then the window can reflow all of its content, but it won't all necessarily update in the same time frame—resulting in windows that appear to be lagging behind and bouncing along as the user dragged or resized a different window.
Another limitation with prior art attempts to manage authority designation in GUI-based computer systems that use windows as their fundamental basis is the fact that the “service window” (i.e., the window that is being hosted into the application) cannot turn around and “re-grant” the hosting application permissions. For example, if the service process needed to ask for help to perform a particular task, it couldn't allow a second service to present a window as the host application, even if the intended use were to simply place another window over the service-provided content because it couldn't grant rights on behalf of a process that it wasn't. Thus, this form of authority management could not be applied recursively while maintaining security.
Thus, there is a need for systems and methods to manage authority designation and event handling among isolated, designated actors within hierarchical GUIs that are both secure and that generalize recursively when applied to the various graphical layers used to construct the windows within the hierarchical GUIs. There is also a need for simple rules that provide per-window granularity regarding content ownership and access, as well as the associated processes for managing them.